H7 support: take 2#77
Conversation
5ca5755 to
aa3b444
Compare
bbf2d2e to
19f907c
Compare
…:eth_interrupt_handler
Force-write RXDESC3
|
For posterity: I'm a bit anxious to merge this, as it overhauls the non-H7 side of things so massively. I think that it is an OK change, but I feel that I have not been able to test this thoroughly enough, and putting it behind a feature flag is impossible (due to the changes to the non-H7 parts). Another important problem is that the PTP implementation on the H7 is weird. Since it uses a second descriptor for storing the timestamp for RX packets, you would imagine that it would: fill the descriptor with the timestamp, increase the RX descriptor pointer by 1, and continue receiving. Sadly, that's not what it seems to do. Instead, it receives the packet, puts the timestamp in the next descriptor, and then attempts to continue receiving in that very same descriptor (which fails, since the descriptor is now no longer owned by the DMA as it contains a timestamp). This doesn't affect usage without the This means that the entire RX pipeline is stalled until the packet is processed, which feels like a really bad/sad tradeoff. I also no longer work at a company that uses embedded rust, so making thorough use of this implementation is not something I can do very well, unfortunately. I may find some more time/motivation to finally get this shipped closer to the end of the year, but it won't go very fast unfortunately |
Due to the unfeasibility of merging of #70, here's a take 2 :)
An attempt at adding STM32H7XX support to
stm32-eth.TODO:
async-awaitdoesn't seem to fire/trigger interrupts like it should.